This one is going to be a straight to the point. Anyone who ever did any IT outsourcing or research in this area knows how frustrating it is to handle international teams and project management.
I bashed my head against these problems many times and decided to make a coherent small list for people who want to tackle them systematically. Here goes:
1. Communication
This roadblock is strengthened by various timezones and becomes especially aggravating if you run multiple teams on different continents. It’s by far the most common reason projects fall apart: lack of managerial oversight and proper control mechanisms.
Huge numbers of instruction manuals and books are written on this particular subject (just look up outsourcing management books, they are endless – and most of them are trash, but that is a whole different tangent).
Overcoming this roadblock it is actually easier than most make it out to be. Use good project management software and hire competent team leads. That’s it.
Get some people in there who can translate from code to human, and you’re gonna be better off than half the companies out there.
Takeaway: wherever your programmers are and whichever language they speak, make sure that the guys who manage their stuff can make coherent strings of syllables, and you will be fine.
2. Scheduling & Management
I already mentioned timezones and languages. Now further stack on top of that the fact that people can:
– Overestimate their capabilities
– Run into accidents
– Uncover unexpected complications
– Circle back to polish things up
– Simply lie about their workflow
When dealing with complex outsourcing projects, I learned one thing in particular: controlling other human beings is a waste of time at best and a destructive mess at worst. Here is what I mean by that: after you’ve made your choice of the team and project manager involved, you’re at their mercy.
If they lied about some inconsequential thing at the start, they will keep lying to you until the project burns like a dumpster fire. If they overestimated what they can do on the tests, you will end up with a Rube Goldberg machine made out of spaghetti code.
Now, my way of overcoming this is a combination of the scientific method and religious philosophy. “Wait… you said what now?” – you may ask. – “I research, test and experiment from the very first day” – I will respond – “And then blindly believe that things will work out”
3. Trust / Dependence
This one is something people rarely talk about in detail. Sure, they sometimes mention that once an outsourcing agency secures a contract they often turn their attention to looking for other clients and hold the “secured” client tightly by their bal-dget.
What few people talk about is how ridiculously common this situation is with sourcing to second and third world countries in particular.
This is why all of the major freelancing platforms that host international labor offer almost ridiculous amounts of financial power to the employer. Not because they hate freelancers, but because culture and especially work ethic are not distributed universally in our world.
Human beings are tribal.
It becomes especially obvious when we are dealing with money/resources. And note how I don’t mean an ethnicity here – for a lot of folks, their tribe is their company and coworkers, whatever hat they happen to be wearing.
What this does mean, however, is that as an employer you are making a deal with another tribe that has a lot of geographical distance between you and them.
You are essentially sending them a caravan of goods today, hoping that next year they will deliver you a caravan of stuff they promised.
Outsourcing at its core is a promise, and promises take a lot of trust.
How do I work around this? I give people their trust, while applying a proven investment law: never put down more resources than you can afford to lose. This puts you into a position of strength negotiations-wise and does wonders to the size of your bal-dget.
You never actually plan to lose anything, you just position yourself in a way where it would not be a big deal.
4. Quality Assurance
If the prior three roadblocks were places where many projects stopped in their tracks and turned around, then this one here is more of a Carmageddon situation. You can see burning wrecks and broken husks on every corner.
Quality assurance sounds like a great thing, right? You have the product already and then you just… assure. That all is good and fine and all that. “Alex, how is this even a roadblock?” – you may ask. This is where the sunk costs fallacy kicks in.
Story Time
Imagine a situation where Bob pays Sally and her team 40 thousand to create some cool software, so that he can resell that cool thing to consumers and make that money back within, say, 6-12 months.
Now, after spending this considerable sum Bob learns when the software gets to the market, it’s not quite a perfect fit.
The profit margins are never quite there. At this stage it’s a no-win situation.
Bob has invested too much to just scrap the project, and is risking to lose even more if he keeps shoveling money into the hole where it goes. Now, some people would say Sally is to blame for this and it was all a calculated ploy so that she could make more money at Bob’s expense.
Sally has a business to run and a team to feed. In her mind she is helping Bob save his burning wreck of a project. After all, her guys are the only ones who understand what’s going on under the hood and how to work this magic machinery.
If Bob tries to find anyone else, his costs would once again skyrocket on the re-training and onboarding costs. To make a bad situation worse, once the launch window is missed competing products are already miles ahead and counting.
The idea stops seeming as good as it did at the start.
Real life is far more complex than this Bob/Sally situation, but the sunk cost problem is quite common in outsourcing. So, how do you deal with a no-win situation? You don’t. You see the burning wreck miles ahead and slow the hell down.
The only way to do this properly is applying timeless management practices and always holding the keys to your project in the palm of your hand. Also, for the love of all that is holy, sell your project before you code it.
– Conclusion
There are smaller roadblocks and more nuance to the entire thing, but I already made this longer than usual – so, expect something short and sweet next time.
Let me know if you have any feedback on my book in the meantime, just launched yesterday and still want to see if it can be made better.